(19) 



3 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



IIINlWIIlllllWlllHlllllinilllllllWIIIIIIII 



(12) 



(43) Date of publication: 

05.06.1996 Bulletin 1996/23 



(H) EP 0 715 243 A1 

EUROPEAN PATENT APPLICATION 

(51) intci.6; G06F 1/00, G06F 17/60 



(21) Application number: 95308414.2 

(22) Date of filing: 23.11.1995 



(84) Designated Contracting States: 


• Pirolli, Peter L.T. 


DE FR GB 


El Cerrrito, California 94530 (US) 




• Merkle, Ralph C. 


(30) Priority: 23.11.1994 US 344773 


Sunnyvale, California 94087 (US) 


(71) Applicant: XEROX CORPORATION 


(74) Representative: Goode, Ian Roy et al 


Rochester New York 14644 (US) 


Rank Xerox Ltd 




Patent Department 


(72) Inventors: 


Parkway 


• Stefik, Mark J. 


Marlow Buckinghamshire SL7 1 YL (GB) 


Woodside, California 94062 (US) 



(54) System for controlling the distribution and use of digital works having a fee reporting 
mechanism 



CD 

m 



o 
o 

3 



(57) A fee accounting mechanism for reporting fees 
associated with the distribution and use of digital works. 
Usage rights and fees are attached to digital works. The 
usage rights define how the digital work may be used or 
further distributed. Usage fees are specified as part of 
a usage right. The digital works and their usage rights 
and fees are stored in repositories (201 ). The repositor- 



ies control access to the digital works. Upon determina- 
tion that the exercise of a usage right requires a fee. the 
repository generates a fee reporting transaction (302). 
Fee reporting is done to a credit server (301 ). The credit 
server collects the fee information and periodically 
transmits it to a billing clearinghouse (303). 
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the present invention. 

of thepreJLnnTention 3 ' 6 6XamP,eS ° f renderin 9 s V s,ems a * ™V be utilized in the currently preferred embodiment 
of thepraLm'inleSn 8 C ° ntemS * * di9ita ' M 35 m3V be UtiMZed in ,he CUrrently preferred embodiment 

„.iii 7 Sin e th 6 JI! UStra, H 5 8 f nte T ' ayOUt ,0f a " individua ' di9ital work of ,he dl '9 i,al work of p i9ure 5 as may be 
utilized in the currently preferred embodiment of the present invention 

invention 6 ? iNUStrateS the com P° nents °< a description block of the currently preferred embodiment of the present 

Figure 8 illustrates a description tree for the contents file layout of the digital work illustrated in Figure 5 
Figure 9 illustrates a portion of a description tree corresponding to the individual digital work illustrated in Figure 6 

1 ,° ' f "" 8trates 9 la y° ut for the rj 9 hts P° rti °n of a description block as may be utilized in the currently preferred 
embodiment of the present invention. 

and i 9 nTen,» 1 riU W rlLni° n ^ PR ' NT USage ri9h,S and is used to illustra «* "strict" 

ana lenient rules for resolving usage rights conflicts. 

Pmhn^m!n 1 , 2 ! S , h a ^ dia9ram °' ^ nardware components of a repository as are utilized in the current^ preferred 
embodiment of the present invention. 

Figure 13 is a block diagram of the functional (logical) components of a repository as are utilized in the currently 
preferred embodiment of the present invention. 

the p7e 9 sent invemion^ illUSlratin9 the b3SiC com P° nenls of a usa 9^ right in the currently preferred embodiment of 
Figure 15 lists the usage rights grammar of the currently preferred embodiment of the present invention 
Figure 16 is a flowchart illustrating the steps of certificate delivery, hotlist checking and performance testing as 
performed ,n a registration transaction as may be performed in the currently preferred embodiment of the present 
invention. r 

Figure 17 is a flowchart illustrating the steps of session information exchange and clock synchronization as may 
be performed in the currently preferred embodiment of the present invention, after each repository in the registration 
transaction has successfully completed the steps described in Figure 16. 
30 ^ R9 T 18 iS 8 flowchar1 illustrating the basic flow for a usage transaction, including the common opening and 
closing step, as may be performed in the currently preferred embodiment of the present invention 

Figure 1 9 is a state diagram of server and client repositories in accordance with a transport protocol followed when 
moving a .digital work from the server to the client repositories, as may be performed in the currently preferred embod- 
iment of the present invention. 

35 OVERVIEW 

A system for controlling use and distribution of digital works is disclosed. The present invention is directed to 
supporting commercial transactions involving digital works. 

Herein the terms "digital work", "work" and "content" refer to any work that has been reduced to a digital repre- 
sentation. This would include any audio, video, text, or multimedia work and any accompanying interpreter (e g soft- 
ware) that may be required for recreating the work. The term composite work refers to a digital work comprised of a 
collection of other digital works. The term "usage rights" or "rights" is a term which refers to rights granted to a recipient 
of a digital work. Generally, these rights define how a digital work can be used and if it can be further distributed Each 
usage right may have one or more specified conditions which must be satisfied before the right may be exercised 

Figure 1 is a high level flowchart omitting various details but which demonstrates the basic operation of the present 
invention. Referring to Figure 1 , a creator creates a digital work, step 1 01 . The creator will then determine appropriate 
usage rights and fees, attach them to the digital work, and store them in Repository i , step 102. The determination of 
appropriate usage rights and fees will depend on various economic factors. The digital work remains securely in Re- 
pository 1 until a request for access is received. The request for access begins with a session initiation by another 
repository. Here a Repos.tory 2 initiates a session with Repository 1 , step 103. As will be described in greater detail 
below, this session initiation includes steps which helps to insure that the respective repositories are trustworthy. As- 
suming that a session can be established, Repository 2 may then request access to the Digital Work for a stated 
purpose, step 1 04. The purpose may be, for example, to print the digital work or to obtain a copy of the digital work 
The purpose will correspond to a specific usage right. In any event, Repository 1 checks the usage rights associated 
with the digital work to determine if the access to the digital work may be granted, step 105. The check of the usage 
rights essent.ally involves a determination of whether a right associated with the access request has been attached to 
the digital work and il all conditions associated with the right are satisfied. If the access is denied, repository 1 terminates 
the session with an error message, step 106. If access is granted, repository 1 transmits the digital work to repository 
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STRUCTURE OF DIGITAL WORKS 

Usage rights are attached directly to digital works. Thus, it is important to understand the structure of a digital work. 
The structure of a digital work, in particular composite digital works, may be naturally organized into an acyclic structure 
5 such as a hierarchy. For example, a magazine has various articles and photographs which may have been created 
and are owned by different persons. Each of the articles and photographs may represent a node in a hierarchical 
structure. Consequently, controls, i.e. usage rights, may be placed on each node by the creator. By enabling control 
and fee billing to be associated with each node, a creator of a work can be assured that the rights and fees are not 
circumvented. 

10 In the currently preferred embodiment, the file information for a digital work is divided into two files: a "contents- 

file and a "description tree" file. From the perspective of a repository, the "contents" file is a stream of addressable 
bytes whose format depends completely on the interpreter used to play, display or print the digital work. The description 
tree file makes it possible to examine the rights and fees for a work without reference to the content of the digital work. 
It should be noted that the term description tree as used herein refers to any type of acyclic structure used to represent 

is the relationship between the various components of a digital work. 

Figure 5 illustrates the layout of a contents file. Referring to Figure 5, a digital work is comprised of story A 510, 
advertisement 511, story B 512 and story C 513. It is assumed that the digital work is stored starting at a relative 
address of 0. Each of the parts of the digital work are stored linearly so that story A 510 is stored at approximately 
addresses 0-30,000, advertisement 511 at addresses 30,001-40,000, story B 512 at addresses 40,001-60,000 and 

20 story C 513 al addresses 60,001 -85K. The detail of story A 510 is illustrated in Figure 6. Referring to Figure 6, the 
story A 510 is further broken down to show text 614 stored at address 0-1500, soldier photo 615 at addresses 
1501-10,000, graphics 616 stored at addresses 10,001-25,000 and sidebar 617 stored address 25,001-30,000. Note 
that the data in the contents file may be compressed (for saving storage) or encrypted (for security). 

From Figures 5 and 6 it is readily observed that a digital work can be represented by its component parts as a 

25 hierarchy. The description tree for a digital work is comprised of a set of related descriptor blocks (d-blocks). The 
contents of each d-block is described with respect to Figure 7. Referring to Figure 7, a d-block 700 includes an identifier 
701 which is a unique identifier for the work in the repository, a starting address 702 providing the start address of the 
first byte of the work, a length 703 giving the number of bytes in the work, a rights portion 704 wherein the granted 
usage rights and their status data are maintained, a parent pointer 705 for pointing to a parent d-block and child pointers 

30 706 for pointing to the child d-blocks. In the currently preferred embodiment, the identifier 701 has two parts. The first 
part is a unique number assigned to the repository upon manufacture. The second part is a unique number assigned 
to the work upon creation. The rights portion 704 will contain a data structure, such as a look-up table, wherein the 
various information associated with a right is maintained. The information required by the respective usage rights is 
described in more detail below. D-blocks form a strict hierarchy. The top d-block of a work has no parent; all other d- 

35 blocks have one parent. The relationship of usage rights between parent and child d-blocks and how conflicts are 
resolved is described below. 

A special type of d-block is a "shell" d-block. A shell d-block adds no new content beyond the content of its parts. 
A shell d-block is used to add rights and fee information, typically by distributors of digital works. 

Figure 8 illustrates a description tree for the digital work of Figure 5. Referring to Figure 8, a top d-block 820 for 

^0 the digital work points to the various stories and advertisements contained therein. Here, the top d-block 820 points to 
d-block 821 (representing story A 510), d-block 822 (representing the advertisement 511), d-block 823 (representing 
story B 512) and and d-block 824 (representing story C 513). 

The portion of the description tree for Story A 510 is illustrated in Figure 9. D-block 925 represents text 614, d- 
block 926 represents photo 615, d-block 927 represents graphics 616 by and d-block 928 represents sidebar 617. 

45 The rights portion 704 of a descriptor block is further illustrated in Figure 10. Figure 10 illustrates a structure which 

is repeated in the rights portion 704 for each right. Referring to Figure 10, each right will have a right code field 1050 
and status information field 1052. The right code field 1050 will contain a unique code assigned to a right. The status 
information field 1052 will contain information relating to the stale of a right and the digital work. Such information is 
indicated below in Table 1 . The rights as stored in the rights portion 704 may typically be in numerical order based on 

50 the right code. 
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for the part, for ancestor d-blocks containing the part and for all descendent d-blocks. By sanctioned, it is meant that 
(1) each of the respective parts must have the right, and (2) any conditions for exercising the right are satisfied. 

It also possible to implement the present invention using a more lenient rule. In the more lenient rule, access to 
the part may be enabled to the descendent parts which have the right, but access is denied to the descendents which 
do not. 

An example of applying both the strict rule and lenient is illustrated with reference to Figure 11 Referring to Figure 
11, a root d-block 1101 has child d-b!ocks 1102-1105. In this case, root d-block represents a magazine, and each of 
the child d-blocks 1102-1105 represent articles in the magazine. Suppose that a request is made to PRINT the digital 
work represented by root d-block 1101 wherein the strict rule is followed. The rights for the root d-block 1101 and child 
d-blocks 1 1 02-1 1 05 are then examined. Root d-block 1 1 01 and child d-blocks 1 1 02 and 1 105 have been granted PRINT 
rights. Child d-block 1103 has not been granted PRINT rights and child d-block 1104 has PRINT rights conditioned on 
payment of a usage fee. 

Under the strict rule the PRINT right cannot be exercised because the child d-block does not have the PRINT right 
Under the lenient rule, the result would be different. The digital works represented by child d-blocks 1102 and 1105 
could be printed and the digital work represented by d-block 1104 could be printed so long as the usage fee is paid 
Only the digital work represented by d-block 1 103 could not be printed. This same result would be accomplished under 
the strict rule if the requests were directed to each of the individual digital works. 

The present invention supports various combinations of allowing and disallowing access. Moreover, as will be 
described below, the usage rights grammar permits the owner of a digital work to specify if constraints may be imposed 
on the work by a container part. The manner in which digital works may be sanctioned because of usage rights conflicts 
would be implementation specific and would depend on the nature of the digital works. 

REPOSITORIES 

In the description of Figure 2, it was indicated that repositories come in various forms. All repositories provide a 
core set of services for the transmission of digital works. The manner in which digital works are exchanged is the basis 
for all transaction between repositories. The various repository types differ in the ultimate functions that they perform. 
Repositories may be devices themselves, or they may be incorporated into other systems. An example is the renderinq 
repository 203 of Figure 2. 

A repository will have associated with it a repository identifier. Typically, the repository identifier would be a unique 
number assigned to the repository at the time of manufacture. Each repository will also be classified as being in a 
particular security class. Certain communications and transactions may be conditioned on a repository being in a 
particular security class. The various security classes are described in greater detail below 

As a prerequisite to operation, a repository will require possession of an identification certificate. Identification 
certificates are encrypted to prevent forgery and are issued by a Master repository A master repository plays the role 
of an authorization agent to enable repositories to receive digital works. Identification certificates must be updated on 
a periodic basis. Identification certificates are described in greater detail below with respect to the registration trans- 
action. 

A repository has both a hardware and functional embodiment. The functional embodiment is typically software 
executing on the hardware embodiment. Alternatively, the functional embodiment may be embedded in the hardware 
embodiment such as an Application Specific Integrated Circuit (ASIC) chip. 

The hardware embodiment of a repository will be enclosed in a secure housing which if compromised, may cause 
the repository to be disabled. The basic components of the hardware embodiment of a repository are described with 
reference to Figure 12. Referring to Figure 12, a repository is comprised of a processing means 1200, storage system 
1207, clock 1205 and external interface 1206. The processing means 1200 is comprised of a processor element 1201 
and processor memory 1202. The processing means 1201 provides controller, repository transaction and usage rights 
transaction functions for the repository. Various functions in the operation of the repository such as decryption and/or 
decompression of digital works and transaction messages are also performed by the processing means 1200. The 
processor element 1201 may be a microprocessor or other suitable computing component. The processor memory 
1 202 would typically be further comprised of Read Only Memories (ROM) and Random Access Memories (RAM). Such 
memories would contain the software instructions utilized by the processor element 1201 in performing the functions 
of the repository. 

The storage system 1 207 is further comprised of descriptor storage 1 203 and content storage 1 204. The description 
tree storage 1203 will store the description tree for the digital work and the content storage will store the associated 
content. The description tree storage 1 203 and content storage 1204 need not be of the same type of storage medium, 
nor are they necessarily on the same physical device. So for example, the descriptor storage 1203 may be stored on 
a solid state storage (for rapid retrieval of the description tree information), while the content storage 1204 may be on 
a high capacity storage such as an optical disk. 
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TABLE 2 (continued) 





REPOSITORY SECURITY LEVELS 




Level 


Description of Security 


5 
10 


3 


General security. Like the previous class plus the requirement of special tools are needed to compromise 

thfi r>hv/fiicfil intAoritx/ of thfi r£»r>o^itrtrv and that moHoct onr r\/r> tirin io tiooH r\r\ oil (i-ekiipmi»0i/Nnr> d^«^i..«^ 
ii y/i lyoiuai ii uoy ( ny ui ii io i Cfjuouui y ai iu u I a l 1 1 iuuooi tfiiufypuvJil IS UocO On all transmissions. rSSSWOrO 

protection is required to use the local user interface. The digital clock system cannot be reset without 
authorization. No works would be stored on removable storage. When executing works as programs, it 
runs them in their own address space and does not give them direct access to any file storage or other 
memory containing system code or works. They can access works only through the transmission 
transaction protocol. 


15 


A 
*+ 


uik© me previous ciass except max mgn level encryption is used on an communications. Sensors are 
used to record attempts at physical and electronic tampering. After such tampering, the repository will 
not perform other transactions until it has reported such tampering to a designated server. 


20 


5 


Like the previous class except that if the physical or digital attempts at tampering exceed some preset 
thresholds that threaten the physical integrity of the repository or the integrity of digital and cryptographic 
barriers, then the repository will save only document description records of history but will erase or destroy 
any digital identifiers that could be misused if released to an unscrupulous. It also modifies any certificates 
of authenticity to indicate that the physical system has been compromised. It also erases the contents 
of designated documents. 




6 


Like the previous class except that the repository will attempt wireless communication to report tampering 
and will employ noisy alarms. 


25 


10 


This would correspond to a very high level of security. This server would maintain constant 
communications to remote security systems reporting transactions, sensor readings, and attempts to 
circumvent security. 



The characterization of security levels described in Table 2 is not intended to be fixed. More important is the idea 
of having different security levels for different repositories. It is anticipated that new security classes and requirements 
will evolve according to social situations and changes in technology. 



Repository User Interface 

35 

A user interface is broadly defined as the mechanism by which a user interacts with a repository in order to invoke 
transactions to gain access to a digital work, or exercise usage rights. As described above, a repository may be em- 
bodied in various forms. The user interface for a repository will differ depending on the particular embodiment. The 
user interface may be a graphical user interface having icons representing the digital works and the various transactions 

40 that may be performed. The user interface may be a generated dialog in which a user is prompted for information. 

The user interface itself need not be part of the repository. As a repository may be embedded in some other device, 
the user interface may merely be a part of the device in which the repository is embedded. For example, the repository 
could be embedded in a "card" that is inserted into an available slot in a computer system. The user interface may be 
a combination of a display, keyboard, cursor control device and software executing on the computer system. 

4S At a minimum, the user interface must permit a user to input information such as access requests and alpha 

numeric data and provide feedback as to transaction status. The user interface will then cause the repository to initiate 
the suitable transactions to service the request. Other facets of a particular user interface will depend on the functionality 
that a repository will provide. 

so CREDIT SERVERS 

In the present invention, fees may be associated with the exercise of a right. The requirement for payment of fees 
is described with each version of a usage right in the usage rights language. The recording and reporting of such fees 
is performed by the credit server. One of the capabilities enabled by associating fees with rights is the possibility of 
55 supporting a wide range of charging models. The simplest model, used by conventional software, is that there is a 
single fee at the time of purchase, after which the purchaser obtains unlimited rights to use the work as often and for 
as long as he or she wants. Alternative models, include metered use and variable fees. A single work can have different 
fees for different uses. For example, viewing a photograph on a display could have different fees than making a hardcopy 
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the keyword takes a list of identifiers. 

In the usage rights language, time is specified in an hours:minutes:seconds (or hh:mm:ss) representation Time 

^WYWMMMAn; P M V°l P f?i fiC Day ' i9ht Time ' may alS0 be specified Da,es are represented as year/ month/day 
or YYYY/MMM/DD). Note that these time and date representations may specify moments in time or units of time 
Money units are specified in terms of dollars. 

Finally, in the usage rights language, various "things" will need to interact with each other. For example, an instance 

hliin'usrng^TuXND"" " ^ * ^ *** **" ^ need '° b ° identified and are "P-*" 

The Usage Rights Grammar is listed in its entirety in Figure 15 and is described below. 

Grammar element 1501 "Digital Work Rights: = (Rights*)" define the digital work rights as a set of rights The 
set o rights attached to a digital work define how that digital work may be transferred, used, performed or played A 
set of rights will attach to the entire digital work and in the case of compound digital works, each of the components of 
the digital work. The usage rights of components of a digital may be different 

Grammar element 1502 "Right : = (Right-Code {Copy-Count} {Control-Spec} {Time-Spec} {Access-Spec} 
{Fee-Spee}) enumerates the content of a right. Each usage right must specify a ,ight code. Each right may also 
optionally specify conditions which must be satisfied before the right can be exercised. These conditions are copy 
count, control, time, access and fee conditions. In the currently preferred embodiment, for the optional elements the 
following defaults apply: copy count equals 1, no time limit on the use of the right, no access tests or a security level 
required to use the nght and no fee is required. These conditions will each be described in greater detail below. 

It is important to note that a digital work may have multiple versions of a right, each having the same right code 
The multiple version would provide alternative conditions and fees for accessing the digital work 

Grammar element 1 503 "Right-Code : = Render-Code I Transport-Code I File-Management-Codel Derivative- 
Z 5 Z Tl f, 9 urat,c,n - Code " distinguishes each of the specific rights into a particular right type (although each 
nght is identified by distinct right codes). In this way, the grammar provides a catalog of possible rights that can be 
associated with parts of digital works. In the following, rights are divided into categories for convenience in describing 

Grammar element 1504 "Render-Code : = [Play : {Player: Player-ID} I Print: {Printer: Printer-ID}]» lists a cat- 
egory of rights all involving the making of ephemeral, transitory, or non-digital copies of the digital work After use the 
copies are erased. 

• Play A process of rendering or performing a digital work on some processor. This includes such things as playing 

digital movies, playing digital music, playing a video game, running a computer program, or displaying a 
document on a display. s 

• Print To render the work in a medium that is not further protected by usage rights, such as printing on paper 

„m G 4 rammar , e | ement 1 505 "Transport-Code : = [Copy I Transfer I Loan (Remaining-Rights: Next-Set-of-Rights}} 
,1 1 ?°? y ,~ 9 I Next " Set of Rf Shts)}" lists a category of rights involving the making of persistent, usable copies 
of the digita work on other repositories. The optional Next-Copy-Rights determine the rights on the work after it is 
transported. If this is not specified, then the rights on the transported copy are the same as on the original. The optional 
Remaining-Rights specify the rights that remain with a digital work when it is loaned out. If this is not specified then 
the default is that no rights can be exercised when it is loaned out 

• Copy Make a new copy of a work 

• Transfer Moving a work from one repository to another. 

• Loan Temporarily loaning a copy to another repository for a specified period of time. 

Grammar element 1506 "File-Management-Code : = Backup {Back-Up-Copy-Rlghts: Next-Set -of Rights)! 
Restore I Delete I Folder I Directory (Name: Hide-Local I Hide - RemoteMParts: Hide-Local I Hide-Remote}" lists 
a category of rights involving operations for file management, such as the making of backup copies to protect the codv 
owner against catastrophic equipment failure. " 

Many software licenses and also copyright law give a copy owner the right to make backup copies to protect against 
catastrophic failure of equipment. However, the making of uncontrolled backup copies is inherently at odds with the 
ability to control usage, since an uncontrolled backup copy can be kept and then restored even after the authorized 
copy was sold. 

The File management rights enable the making and restoring of backup copies in a way that respects usage rights 
honoring the requirements of both the copy owner and the rights grantor and revenue owner. Backup copies of work 
descriptions (including usage rights and fee data) can be sent under appropriate protocol and usage rights control to 
other document repositories of sufficiently high security. Further rights permit organization of digital works into folders 
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Time Specification 

It is often desirable to assign a start date or specify some duration as to when a right may be exercised. Grammar 
element 1512 "Time-Spec : = ({Fixed-Interval I Sllding-lnterval I Meter-Time} Until: Expiration-Date)" provides for 
5 specification of time conditions on the exercise of a right. Rights may be granted for a specified time. Different kinds 
of time specifications are appropriate for different kinds of rights. Some rights may be exercised during a fixed and 
predetermined duration. Some rights may be exercised for an interval that starts the first time that the right is invoked 
by some transaction. Some rights may be exercised or are charged according to some kind of metered time, which 
may be split into separate intervals. For example, a right to view a picture for an hour might be split into six ten minute 
10 viewings or four fifteen minute viewings or twenty three minute viewings. 

The terms "time" and "date" are used synonymously to refer to a moment in time. There are several kinds of time 
specifications. Each specification represents some limitation on the times over which the usage right applies. The 
Expiration-Date specifies the moment at which the usage right ends. For example, if the Expiration-Date is "Jan 1, 
1995," then the right ends at the first moment of 1995. If the Expiration-Date is specified as *forever*. then the rights 
? 5 are interpreted as continuing without end. If only an expiration date is given, then the right can be exercised as often 
as desired until the expiration date. 

Grammar element 1 51 3 "Fixed-Interval : = From: Start-Time" is used to define a predetermined interval that runs 
from the start time to the expiration date. 

Grammar element 1514 "SHding-lnterval : = Interval: Use-Duration" is used to define an indeterminate (or 
20 "open") start time. It sets limits on a continuous period of time over which the contents are accessible. The period starts 
on the first access and ends after the duration has passed or the expiration date is reached, whichever comes first. 
For example, if the right gives 10 hours of continuous access, the use-duration would begin when the first access was 
made and end 10 hours later. 

Grammar element 1515 "Meter-Time: = Time-Remaining: Remaining-Use" is used to define a "meter time," that 
2S is, a measure of the time that the right is actually exercised. It differs from the Sliding-lntorval specification in that the 
time that the digital work is in use need not be continuous. For example, if the rights guarantee three days of access, 
those days could be spread out over a month. With this specification, the rights can be exercised until the meter time 
is exhausted or the expiration date is reached, whichever comes first. 
Remaining-Use: = Time-Unit 
30 Start-Time: = Time-Unit 

Use-Duration: = Time-Unit 

All of the time specifications include time-unit specifications in their ultimate instantiation. 
Security Class and Authorization Specification 

3S 

The present invention provides for various security mechanisms to be introduced into a distribution or use scheme. 
Grammar element 1516 "Access-Spec : = ({SC: Security-Class} {Authorization: Authorization-ID*} {Other-Au- 
thorization: Authorization-ID*} {Ticket: Ticket-ID})" provides a means for restricting access and transmission. Ac- 
cess specifications can specify a required security class for a repository to exercise a right or a required authorization 
40 test that must be satisfied. 

The keyword "SC:" is used to specify a minimum security level for the repositories involved in the access. If "SC: 
" is not specified, the lowest security level is acceptable. 

The optional "Authorization:" keyword is used to specify required authorizations on the same repository as the 
work. The optional "Other-Authorization:" keyword is used to specify required authorizations on the other repository 
4 $ in the transaction. 

The optional "Ticket:" keyword specifies the identity of a ticket required for the transaction. A transaction involving 
digital tickets must locate an appropriate digital ticket agent who can "punch" or otherwise validate the ticket before 
the transaction can proceed. Tickets are described in greater detail below. 

In a transaction involving a repository and a document server, some usage rights may require that the repository 

50 have a particular authorization, that the server have some authorization, or that both repositories have (possibly dif- 
ferent) authorizations. Authorizations themselves are digital works (hereinafter referred to as an authorization object) 
that can be moved between repositories in the same manner as other digital works. Their copying and transferring is 
subject to the same rights and fees as other digital works. A repository is said to have an authorization if that author- 
ization object is contained within the repository 

55 In some cases, an authorization may be required from a source other than the document server and repository. 

An authorization object referenced by an Authorization-ID can contain digital address information to be used to set up 
a communications link between a repository and the authorization source. These are analogous to phone numbers. 
For such access tests, the communication would need to be established and authorization obtained before the right 
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with tickets or authorizations that could indicate that the consumer is a wholesaler or that he is a preferred customer, 
or that the seller be authorized in some way. The amount of money in the Max: field is the maximum amount that the 
use will cost. This is the amount that is tentatively debited from the credit server. However, when the transaction is 
ultimately reconciled, any excess amount will be returned to the consumer in a separate transaction. 
5 Grammar element 1523 "Call-For-Price-Spec : = Call-For-Price u is similar to a "Best-Price-Spec" in that it is 

intended to accommodate cases where prices are dynamic. A Call-For-Price Spec requires a communication with a 
dealer to determine the price. This option cannot be exercised if the repository cannot communicate with a dealer at 
the time that the right is exercised. It is based on a secure transaction whereby the dealer names a price to exercise 
the right and passes along a deal certificate which is referenced or included in the billing process 
10 Grammar element 1 524 "Scheduled- Fee- Spec: = (Schedule: (Time-Spec Regular-Fee-Spec)*)" is used to pro- 

vide a schedule of dates over which the fee specifications change. The fee specification with the most recent date not 
in the future is the one that is in effect. This is similar to but more general than the scheduled discount. It is more 
general, because it provides a means to vary the fee agreement for each time period. 

Grammar element 1525 "Markup-Spec: = Markup: percentage To: Account-ID" is provided for adding a per- 
centage to the fees already being charged. For example, a 5% markup means that a fee of 5% of cumulative fee so 
far will be allocated to the distributor. A markup specification can be applied to all of the other kinds of fee specifications 
It is typically used in a shell provided by a distributor. It refers to fees associated with d-blocks that are parts of the 
current d-block. This might be a convenient specification for use in taxes, or in distributor overhead. 

20 REPOSITORY TRANSACTIONS 

When a user requests access to a digital work, the repository will initiate various transactions. The combination 
of transactions invoked will depend on the specifications assigned for a usage right. There are three basic types of 
transactions, Session Initiation Transactions, Financial Transactions and Usage Transactions. Generally, session ini- 
tiation transactions are initiated first to establish a valid session. When a valid session is established, transactions 
corresponding to the various usage rights are invoked. Finally, request specific transactions are performed. 

Transactions occur between two repositories (one acting as a server), between a repository and a document play- 
back platform (e.g. for executing or viewing), between a repository and a credit server or between a repository and an 
authorization server. When transactions occur between more than one repository, it is assumed that there is a reliable 
communication channel between the repositories. For example, this could be a TCP/IP channel or any other commer- 
cially available channel that has built-in capabilities for detecting and correcting transmission errors. However, it is not 
assumed that the communication channel is secure. Provisions for security and privacy are part of the requirements 
for specifying and implementing repositories and thus form the need for various transactions. 

55 Message Transmission 

Transactions require that there be some communication between repositories. Communication between reposi- 
tories occurs in units termed as messages. Because the communication line is assumed to be unsecure, all commu- 
nications with repositories that are above the lowest security class are encrypted utilizing a public key encryption 
technique. Public key encryption is a well known technique in the encryption arts. The term key refers to a numeric 
code that is used with encryption and decryption algorithms. Keys come in pairs, where "writing keys" are used to 
encrypt data and "checking keys" are used to decrypt data. Both writing and checking keys may be public or private 
Public keys are those that are distributed to others Private keys are maintained in confidence. 

Key management and security is instrumental in the success of a public key encryption system. In the currently 
preferred embodiment, one or more master repositories maintain the keys and create the identification certificates 
used by the repositories. 

When a sending repository transmits a message to a receiving repository, the sending repository encrypts all of 
its data using the public writing key of the receiving repository. The sending repository includes its name, the name of 
the receiving repository, a session identifier such as a nonce (described below), and a message counter in each mes- 
sage. 

In this way, the communication can only be read (to a high probability) by the receiving repository, which holds the 
private checking key for decryption. The auxiliary data is used to guard against various replay attacks to security If 
messages ever arrive with the wrong counter or an old nonce, the repositories can assume that someone is interfering 
with communication and the transaction terminated. 

The respective public keys for the repositories to be used for encryption are obtained in the registration transaction 
described below. 
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second key is encrypted using the public key of repository-2, step 1702 and is sent to repository-2, step 1703. Upon 
receipt, repository-2 decrypts the second key, step 1704. The second key is used to decrypt messages in subsequent 
communications. When each repository has completed this step, they are both convinced that the other repository is 
bona fide and that they are communicating with the original. Each repository has given the other a key to be used in 
5 decrypting further communications during the session. Since that key is itself transmitted in the public key of the re- 
ceiving repository only it will be able to decrypt the key which is used to decrypt subsequent messages. 

After the session information is exchanged, the repositories must synchronize their clocks Clock synchronization 
is used by the repositories to establish an agreed upon time base for the financial records of their mutual transactions. 
Referring back to Figure 1 7, repository-2 initiates clock synchronization by generating a time stamp exchange message, 

to step 1705, and transmits it to repository- 1, step 1706. Upon receipt, repository-1 generates its own time stamp mes- 
sage, step 1707 and transmits it back to repository-2, step 1708. Repository-2 notes the current time, step 1709 and 
stores the time received from repository-1 , step 1710. The current time is compared to the time received from repository- 
1, step 1711. The difference is then checked to see if it exceeds a predetermined tolerance (e.g. one minute), step 
1712. If it does, repository-2 terminates the transaction as this may indicate tampering with the repository, step 1713. 
if not repository-2 computes an adjusted time delta, step 1714. The adjusted time delta is the difference between the 
clock time of repository-2 and the average of the times from repository-1 and repository-2. 

To achieve greater accuracy, repository-2 can request the time again up to a fixed number of times (e.g. five times), 
repeat the clock synchronization steps, and average the results. 

A second session initiation transaction is a Login transaction. The Login transaction is used to check the authenticity 

20 of a user requesting a transaction. A Login transaction is particularly prudent for the authorization of financial transac- 
tions that will be charged to a credit server. The Login transaction involves an interaction between the user at a user 
interface and the credit server associated with a repository. The information exchanged here is a login string supplied 
by the repository/credit server to identify itself to the user, and a Personal Identification Number (PIN) provided by the 
user to identify himself to the credit server. In the event that the user is accessing a credit server on a repository different 

25 from the one on which the user interface resides, exchange of the information would be encrypted using the public and 
private keys of the respective repositories. 

Billing Transactions 

30 Billing Transactions are concerned with monetary transactions with a credit server. Billing Transactions are carried 

out when all other conditions are satisfied and a usage fee is required for granting the request. For the most part, billing 
transactions are well understood in the state of the art. These transactions are between a repository and a credit server, 
or between a credit server and a billing clearinghouse. Briefly, the required transactions include the following: 

35 • Registration and LOG IN transactions by which the repository and user establish their bona fides to a credit server. 
These transactions would be entirely internal in cases where the repository and credit server are implemented as 
a single system. 

• Registration and LOG IN transactions, by which a credit server establishes its bona fides to a billing clearinghouse. 

• An Assign-fee transaction to assign a charge. The information in this transaction would include a transaction iden- 
40 tifier, the identities of the repositories in the transaction, and a list of charges from the parts of the digital work. If 

there has been any unusual event in the transaction such as an interruption of communications/that information 
is included as well. 

• A Begin-charges transaction to assign a charge. This transaction is much the same as an assign-fee transaction 
except that it is used for metered use. It includes the same information as the assign-fee transaction as well as 

45 the usage fee information. The credit-server is then responsible for running a clock. 

• An End-charges transaction to end a charge for metered use. (In a variation on this approach, the repositories 
would exchange periodic charge information for each block of time.) 

• A report-charges transaction between a personal credit server and a billing clearinghouse. This transaction is 
invoked at least once per billing period. It is used to pass along information about charges. On debit and credit 

50 cards, this transaction would also be used to update balance information and credit limits as needed. 

All billing transactions are given a transaction ID and are reported to the credit severs by both the server and the 
client. This reduces possible loss of billing information if one of the parties to a transaction loses a banking card and 
provides a check against tampering with the system. 



55 



Usage Transactions 

After the session initiation transactions have been completed, the usage request may then be processed. To sim- 
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requested right is not in the set of remaining rights, the server terminates the transaction, step 1805. 

If Loan is not a usage right for the digital work or if all copies have not been loaned out or the requested right is in 
the set of remaining rights, fee conditions for the right are then checked, step 1815. This will initiate various financial 
transactions between the repository and associated credit server. Further, any metering of usage of a digital work will 
commence. If any financial transaction fails, the transaction terminates per step 1805. 

It should be noted that the order in which the conditions are checked need not follow the order of steps 1 806-1 81 5. 

At this point, right specific steps are now performed and are represented here as step 1816. The right speci fi c 
steps are described in greater detail below. 

The common closing transaction steps are now performed. Each of the closing transaction steps are performed 
by the server after a successful completion of a transaction. Referring back to Figure 18, the copies in use value for 
the requested right is decremented by the number of copies involved in the transaction, step 1817. Next, if the right 
had a metered usage fee specification, the server subtracts the elapsed time from the Remain ing-Use-Time associated 
with the right for every part involved in the transaction, step 1818. Finally, if there are fee specifications associated 
with the right, the server initiates End-Charge financial transaction to confirm billing, step 1819. 

Transmission Protocol 

An important area to consider is the transmission of the digital work from the server to the requester. The trans- 
mission protocol described herein refers to events occurring after a valid session has been created. The transmission 
protocol must handle the case ol disruption in the communications between the repositories. It is assumed that inter- 
ference such as injecting noise on the communication channel can be detected by the integrity checks (e.g., parity, 
checksum, etc.) that are built into the transport protocol and are not discussed in detail herein. 

The underlying goal in the transmission protocol is to preclude certain failure modes, such as malicious or accidental 
interference on the communications channel. Suppose, for example, that a user pulls a card with the credit server at 
a specific time near the end of a transaction. There should not be a vulnerable time at which "pulling the card 0 causes 
the repositories to fail to correctly account for the number of copies of the work that have been created. Restated, there 
should be no time at which a party can break a connection as a means to avoid payment after using a digital work. 

If a transaction is interrupted (and fails), both repositories restore the digital works and accounts to their state prior 
to the failure, modulo records of the failure itself. 

Figure 19 is a state diagram showing steps in the process of transmitting information during a transaction. Each 
box represents a state of a repository in either the server mode (above the central dotted line 1 901 ) or in the requester 
mode (below the dotted line 1 901 ). Solid arrows stand for transitions between states. Dashed arrows stand for message 
communications between the repositories. A dashed message arrow pointing to a solid transition arrow is interpreted 
as meaning that the transition takes place when the message is received. Unlabeled transition arrows take place 
unconditionally. Other labels on state transition arrows describe conditions that trigger the transition. 

Referring now to Figure 19, the server is initially in a state 1902 where a new transaction is initiated via start 
message 1903. This message includes transaction information including a transaction identifier and a count of the 
blocks of data to be transferred. The requester, initially in a wait state 1904 then enters a data wait state 1905. 

The server enters a data transmit state 1906 and transmits a block of data 1907 and then enters a wait for ac- 
knowledgement state 1908. As the data is received, the requester enters a data receive state 1909 and when the data 
blocks are completely received it enters an acknowledgement state 1 91 0 and transmits an Acknowledgement messaqe 
1911 to the server. 

If there are more blocks to send, the server waits until receiving an Acknowledgement message from the requester. 
When an Acknowledgement message is received it sends the next block to the requester and again waits for acknowl- 
edgement. The requester also repeats the same cycle of states. 

If the server detects a communications failure before sending the last block, it enters a cancellation state 1912 
wherein the transaction is cancelled. Similarly, if the requester detects a communications failure before receiving the 
last block it enters a cancellation state 1913. 

If there are no more blocks to send, the server commits to the transaction and waits for the final Acknowledgement 
in state 1 91 4. If there is a communications failure before the server receives the final Acknowledgement message, it 
still commits to the transaction but includes a report about the event to its credit server in state 1915. This report serves 
two purposes. It will help legitimize any claims by a user of having been billed for receiving digital works that were not 
completely received. Also it helps to identify repositories and communications lines that have suspicious patterns of 
use and interruption. The server then enters its completion state 1916. 

On the requester side, when there are no more blocks to receive, the requester commits to the transaction in state 

1917. If the requester detects a communications failure at this state, it reports the failure to its credit server in state 

1918, but still commits to the transaction. When it has committed, it sends an acknowledgement message to the server. 
The server then enters its completion state 1919. 



19 

3NSDCCID: <EP 0715243A1„I_> 



EP 0 715 243 A1 



• The requester records the work contents, data, and usage rights and stores the work. 

• The server decrements its copy count by the number of copies involved in the transaction. 

• The repositories perform the common closing transaction steps. 

• If the number of copies remaining in the server is now zero, it erases the digital work from its memory. 
The Loan Transaction 

A loan transaction is a mechanism for loaning copies of a digital work. The maximum duration of the loan is de- 
termined by an internal parameter of the digital work. Works are automatically returned after a predetermined time 
10 period. 

• The requester sends the server a message to initiate the Transfer Transaction. This message indicates the work 
to be loaned, the version of the loan right to be used in the transaction, the destination address information for 
placing the work, the number of copies involved, the file data for the work, and the period of the loan. 

> The server checks the validity of the requested loan period, and ends with an error if the period is not valid. Loans 
for a loaned copy cannot extend beyond the period of the original loan to the server. 

• The repositories perform the common opening transaction steps. 

• The server transmits the requested contents and data to the requester. If a Next-Set-Of-Rights has been provided, 
those rights are transmitted as the rights for the work. Otherwise, the rights of the original are transmitted, as 

20 modified to reflect the loan period. 

The requester records the digital work contents, data, usage rights, and loan period and stores the work. 
The server updates the usage rights information in the digital work to reflect the number of copies loaned out. 

• The repositories perform the common closing transaction steps. 
The server updates the usage rights data for the digital work. This may preclude use of the work until it is returned 
from the loan. The user on the requester platform can now use the transferred copies of tho digital work. A user 
accessing the original repository cannot use the digital work , unless there are copies remaining. What happens 
next depends on the order of events in time. 
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Case 1 • lf the time of the loan period is not yet exhausted and the requester sends the repository a Return message. 

• The return message includes the requester identification, and the transaction ID. 

• The server decrements the copies-in-use field by the number of copies that were returned. (If the number of 
digital works returned is greater than the number actually borrowed, this is treated as an error.) This step may 
now make the work available at the server for other users. 

• The requester deactivates its copies and removes the contents from its memory. 

Case 2- I* the time of the loan period is exhausted and the requester has not yet sent a Return message. 

• The server decrements the copies-in-use field by the number digital works that were borrowed. 

40 * Tne requester automatically deactivates its copies of the digital work. It terminates all current uses and erases 

the digital work copies from memory. One question is why a requester would ever return a work earlier than 
the period of the loan, since it would be returned automatically anyway. One reason for early return is that 
there may be a metered fee which determines the cost of the loan. Returning early may reduce that fee. 

The Play Transaction 

A play transaction is a request to use the contents of a work. Typically, to "play" a work is to send the digital work 
through some kind of transducer, such as a speaker or a display device. The request implies the intention that the 
contents will not be communicated digitally to any other system. For example, they will not be sent to a printer, recorded 
on any digital medium, retained after the transaction or sent to another repository. 

This term "play" is natural for examples like playing music, playing a movie, or playing a video game. The general 
form of play means that a "player" is used to use the digital work. However, the term play covers all media and kinds 
of recordings. Thus one would "play" a digital work, moaning, to render it for reading, or play a computer program, 
meaning to execute it. For a digital ticket the player would be a digital ticket agent. 
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The requester sends the server a message to initiate the play transaction. This message indicates the work to be 
played, the version of the play right to be used in the transaction, the identity of the player being used, and the file 
data for the work. 
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such as a magneto-optical storage system or magnetic tape. This creation of a non-repository archive file is as secure 
as the encryption process. Such non-repository archive storage is considered a form of "p r ' nt ' n g u an d is controlled by 
a print right with a specified "archive-printer. u An archive-printer device is programmed to save the encrypted contents 
file (but not the description file) offline in such a way that it can be retrieved. 

5 

The Restore Transaction 

A Restore transaction is a request to convert an encrypted backup copy of a digital work into a usable copy. A 
restore operation is intended to be used to compensate for catastrophic media failure. Like all usage rights, restoration 
io rights can include fees and access tests including authorization checks. 

• The requester sends the server a message to initiate a Restore transaction. This message indicates the work to 
be restored, the version of the restore right for the transaction, the destination address information for placing the 
work, and the file data for the work. 

• The server verifies that the contents file is available (i.e. a digital work corresponding to the request has been 
backed-up.) If it is not, it ends the transaction with an error. 

• The repositories perform the common opening transaction steps. 

• The server retrieves the key from the restoration file. It decrypts the work contents, data, and usage rights. 

• The server transmits the requested contents and data to the requester according to the transmission protocol. If 
20 a Next-Sel-Of-Rights has been provided, those rights are transmitted as the rights for the work. Otherwise, a set 

of default rights for backup files of the original are transmitted by the server. 

• The requester stores the digital work. 

• The repositories perform the common closing transaction steps. 

25 The Delete Transaction 

A Delete transaction deletes a digital work or a number of copies of a digital work from a repository. Practically all 
digital works would have delete rights. 

30 • The requester sends the server a message to initiate a delete transaction. This message indicates the work to be 
deleted, the version of the delete right for the transaction. 

• The repositories perform the common opening transaction steps. 

• The server deletes the file, erasing it from the file system. 

• The repositories perform the common closing transaction steps. 
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The Directory Transaction 



A Directory transaction is a request for information about folders, digital works, and their parts. This amounts to 
roughly the same idea as protection codes in a conventional file system like TENEX, except that it is generalized to 
40 the full power of the access specifications of the usage rights language. 

The Directory transaction has the important role of passing along descriptions of the rights and fees associated 
with a digital work. When a user wants to exercise a right, the user interface of his repository implicitly makes a directory 
request to determine the versions of the right that are available. Typically these are presented to the user -- such as 
with different choices of billing for exercising a right. Thus, many directory transactions are invisible to the user and 
45 are exercised as part of the normal process of exercising all rights. 

• The requester sends the server a message to initiate a Directory transaction. This message indicates the file or 
folder that is the root of the directory request and the version of the directory right used for the transaction. 

• The server verifies that the information is accessible to the requester. In particular, it does not return the names 
so of any files that have a HIDE-NAME status in their directory specifications, and it does not return the parts of any 

folders or files that have HIDE-PARTS in their specification. If the information is not accessible, the server ends 
the transaction with an error. 

• The repositories perform the common opening transaction steps. 

The server sends the requested data to the requester according to the transmission protocol. 
55 • The requester records the data. 

• The repositories perform the common closing transaction steps. 
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it would be a reasonable variation to cause a new copy of the work to be made. 

• The requester sends the server a message to initiate an Edit transaction. This message indicates the work to be 
edited, the version of the edit right to be used in the transaction, the file data for the work (including its size), the 

5 process-ID for the process, and the number of copies involved. 

• The server checks the compatibility of the process-ID to be used by the requester against any process-ID speci- 
fication in the right. If they are incompatible, it ends the transaction with an error. 

• The repositories perform the common opening transaction steps. 

• The requester uses the process to change the contents of the digital work as desired. (For example, it can select 
to and duplicate parts of it; combine it with other information; or compute functions based on the information. This 

can amount to editing text, music, or pictures or taking whatever other steps are useful in creating a derivative work.) 

• The repositories perform the common closing transaction steps. 

The edit transaction is used to cover a wide range of kinds of works. The category describes a process that takes 
15 as its input any portion of a digital work and then modifies the input in some way. For example, for text, a process for 
editing the text would require edit rights. A process for "summarizing" or counting words in the text would also be 
considered editing. For a music file, processing could involve changing the pitch or tempo, or adding reverberations, 
or any other audio effect. For digital video works, anything which alters the image would require edit rights. Examples 
would be colorizing, scaling, extracting still photos, selecting and combining frames into story boards, sharpening with 
20 signal processing, and so on. 

Some creators may want to protect the authenticity of their works by limiting the kinds of processes that can be 
performed on them. If there are no edit rights, then no processing is allowed at all. A processor identifier can be included 
to specify what kind of process is allowed. If no process identifier is specified, then arbitrary processors can be used. 
For an example of a specific process, a photographer may want to allow use of his photograph but may not want it to 
25 be colorized. A musician may want to allow extraction of portions of his work but not changing of the tonality. 

Authorization Transactions 

There are many ways that authorization transactions can be defined. In the following, our preferred way is to simply 
30 define them in terms of other transactions that we already need for repositories. Thus, it is convenient sometimes to 
speak of "authorization transactions, 11 but they are actually made up of other transactions that repositories already have. 

A usage right can specify an authorization-ID, which identifies an authorization object (a digital work in a file of a 
standard format) that the repository must have and which it must process. The authorization is given to the generic 
authorization (or ticket) server of the repository which begins to interpret the authorization. 
35 As described earlier, the authorization contains a server identifier, which may just be the generic authorization 

server or it may be another server. When a remote authorization server is required, it must contain a digital address. 
It may also contain a digital certificate. 

If a remote authorization server is required, then the authorization process first performs the following steps: 

40 • The generic authorization server attempts to set up the communications channel. (If the channel cannot be set 
up, then authorization fails with an error.) 

• When the channel is set up, it performs a registration process with the remote repository. (If registration fails, then 
the authorization fails with an error) 

• When registration is complete, the generic authorization server invokes a "Play" transaction with the remote re- 
pository, supplying the authorization document as the digital work to be played, and the remote authorization server 
(a program) as the "player." (If the player cannot be found or has some other error, then the authorization fails with 
an error.) 

• The authorization server then "plays" the authorization. This involves decrypting it using either the public key of 
the master repository that issued the certificate or the session key from the repository that transmitted it. The 

50 authorization server then performs various tests. These tests vary according to the authorization server. They 

include such steps as checking issue and validity dates of the authorization and checking any hot-lists of known 
invalid authorizations. The authorization server may require carrying out any other transactions on the repository 
as well, such as checking directories, getting some person to supply a password, or playing some other digital 
work. It may also invoke some special process for checking information about locations or recent events. The 

55 "script" for such steps is contained within the authorization server. 

• If all of the required steps are completed satisfactorily, the authorization server completes the transaction normally, 
signaling that authorization is granted. 
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comprising a fee type and fee parameters which define a fee to be paid in connection with the exercise of said 
usage right; 

a communication medium for coupling repositories to enable communication between repositories- and 

a plurality of repositories, each of said repositories comprising: 

an external interface for removably coupling to said communications medium; 

storage means for storing digital works having attached usage rights and fees; 

requesting means for generating a request to access a digital work stored in another of said plurality of repos- 
itories, said request indicating a particular usage right; and 

processing means for processing requests to access digital works stored in said storage means and for gen- 
erating fee transactions when a request indicates a usage right that is attached to a digital work and said usage 
right specifies usage fee information; 

each of said plurality of repositories being removably coupled to a credit server, said credit server being 
arranged for recording fee transactions from said repository and subsequently reporting said fee transactions 
to a billing clearinghouse. 

The fee reporting system as recited in Claim 1 wherein said fee type of said fee information is a metered use fee 
a per use fee, a best price fee, a scheduled fee.or a mark-up fee. 

A method for reporting fees associated with the distribution and use of digital works in a system for controlling the 
distribution and use of digital works, said method comprising the steps of: 

a) attaching one or more usage rights to a digital work, each of said one or more usage rights comprising an 
indicator of how said digital work may be distributed or used and a usage fee to be paid upon exercise of said 
right; 

b) storing said digital work and attached one or more usage rights in a server repository, said server repository 
controlling access to said digital work; 

c) said server repository receiving a request to access said digital work from a requesting repository 

d) said server repository identifying a usage right associated with said access request; 

e) said server repository determining if said identified usage right is the same as one of said one or more 
usage rights attached to said digital work; 

f ) if said identified usage right is not the same as any one of said one or more usage rights attached to said 
digital work, said server repository denying access to said digital work; 

g) if said usage right is included with said digital work, said server repository determining if a usage fee is 
associated with the exercise of said usage right; 

h) if a usage fee is associated with usage right, said server repository calculating said usage fee- 

i) said server repository transmitting a first assign fee transaction identifying said requesting repository as a 
payer for said usage fee to a first credit server; 

j) said requesting repository transmitting a second assign fee transaction identifying said requesting repository 
as a payer for said usage fee to a second credit server; 

k) said server repository transmitting said digital work to said requesting repository; 

I) said server repository transmitting a first confirm fee transaction to said first credit server; and 

m) said requesting repository transmitting a second confirm fee transaction to said second credit server. 

The method as recited in Claim 3 wherein said digital work is comprised of a plurality of independent digital works 
and said step of said server calculating said usage fee is further comprised of the step of reporting the usaqe fees 
for each of the plurality of independent digital works. 

A method for reporting fees associated with Ihe distribution and use of digital works in a system for controlling the 
distribution and use of digital works, said method comprising the steps of: 

a) attaching one or more usage rights to a digital work, each of said one or more usage rights comprising an 
indicator of how said digital work may be distributed or used and a usage fee to be paid for exercise of said right- 

b) storing said digital work and said attached one or more usage rights in a server repository, said server 
repository controlling access to said digital work; 

c) said server repository receiving a request to access said digital work from a requesting repository: 

d) said server repository identifying a usage right associated with said access request; 

e) said server repository determining if said digital work has attached thereto said identified usage right 

f) if sa«d identified usage right is not attached to said digital work, said server repository denying access to 
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1501 — Digital Work Rights: = i Rights*) 

1502 — Right : = (Right-Code {Copy-Count} {Control-Spec} {Time-Spec } 

{Acce93-Spec} {Fee-Spec}) 
1503 — Right-Code := Render-Code | Transport-Code | File-Management- 
Code| Derivative-Works- Code | Configuration-Code 
7504 —Render-Code : = [ Play : {Player: Player- ID} | Print: {Printer: Printer-ID}] 

7505— Transport-Code : = [Copy | Transfer | Loan {Remaining- Rights: 
Next-Set-of-Rights}]{(Next-Copy-Rights: Next-Set-of-Rights)} 

7506— File-Manageraent-Code := Backup {Back-Up-Copy-Rights: 

Next-Set-of-Rights} | Restore | Delete | Folder 
| Directory {Name: Hide-Local | Hide-Remote} 
{Parts: Hide-Local | Hide-Remote} 

7507— Derivative-Works-Code := [Extract | Embed | Edit{Process: 

Process-ID}] {Next-Copy-Rights : 
Next-Set-of Rights} 
7505— Configuration-Code : = Install | Uninstall 
7509— Next-Set-of-Rights: = {(Add: Set-Of-Rights)} {(Delete: 

Set-Of-Rights)} {(Replace: Set-Of-Rights )}{(Keep: Set-Of-Rights )} 
1510 — -Copy-Count : = (Copies:positive-integer | 0 1 Unlimited) 
7577 —Control-Spec := (Control: {Restrictable | Unrestrictable} 

{Unchargeable | Chargeable}) 
7572— Time-Spec := ({Fixed-Interval | Sliding- Interval | Meter-Time} 

Until: Expiration- Date) 

7573 — Fixed-Interval From: Start-Time 

7574— — Sliding-Interval := Interval: Use-Duration 

7575 — Meter-Time: = Time-Remaining: Remaining-Use 

7576 — Access-Spec := ({SC: Security-Class} {Authorization: Authorization- ID*} 
{Other-Authorization: Authorization-ID*} {Ticket: Ticket-ID}) 

7577 Fee-Spec: = {Scheduled-Discount} Regular-Fee-Spec | Scheduled-Fee-Spec | 

Markup-Spec 

151 8-— Scheduled-Discount: = Scheduled-Discount: (Scheduled-Discount: 

(Time-Spec Percentage)*) 
7579-— Regular-Fee-Spec := ({Fee: [Incentive:} [Per-Use-Spec | Metered-Rate- 

Spec | Best-Price-Spec | Call-For-Price-Spec] 
{Min: Money-Unit Per: Time-Spec}{Max: 
Money-Unit Per: Time-Spec} To: Account-ID) 
7520 — Per-Use-Spec: = Per-Use: Money-unit 

7527 — Metered-Rate-Spec : = Metered: Money-Unit Per: Time-Spec 

7522 — Best-Price-Spec : = Best-Price: Money-unit Max: Money-unit 

7523 — Call-For-Price-Spec := Call-For -Price 

7524 — Scheduled-Fee-Spec: = (Schedulfe: (Time-Spec Regular-Fee-Spec)* ) 
7525— Markup-Spec— Markup: percentage To: Account-ID 

Fig. 15 
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